I encountered this issue with an app I'm writing that accepts arguments. With some troubleshooting I've determined that this is an inherent behaviour in how Xcode 16 compiles SwiftUI apps and how macOS 15 launches them. The issue: Launching the app as open /Applications/AppName.app --args --arg1 --arg2 --arg3 etc should allow the app to process the arguments as CommandLine.arguments and this is still the case. How the app sees arguments is unchanged and doesn't matter if you use CommandLine.arguments or swift argument parser or don't have arguments at all. This will affect any SwiftUI app as I'll demonstrate below. The problem is that if you use a mix of arguments as --arg value pairs or --arg as a flag, then depending on the order the arguments are provides, the app won't launch properly. The icon will appear in the dock but no window appears until you click the icon in the dock. (BTW, having "Application is agent (UIElement)" set to YES in the Info.plist makes this task rather difficult.) In testing if you use all flags, it's fine. if the flags are in pairs, it's fine. if you have one flag and then a --arg value pair, you will see the issue. If you reverse the order so the flag is after then it works fine. How to replicate: On macOS 15 and Xcode 16 Open Xcode Create a new macOS App (called demoapp in my example) Select SwiftUI as the interface Build That it. Don't add anything and just build the boilerplate hello world app that Xcode makes for you. Once that's built, cd to your /Build/Products/Debug/ directory in terminal and try the following (this happens if you build for release as well): note, the app window will display when you click the icon in the dock, just not on initial launch # three single arguments open ./demoapp.app --args --foo --bar --baz # App window displays as expected # one single argument, one arg value pair open ./demoapp.app --args --foo --bar baz # The app window will not appear. # same arguments as before but the single argument is after the arg value pair open ./demoapp.app --args --bar baz --foo # App window displays as expected # arg[1] without `-` or `--` prefix open ./demoapp.app --args foo --bar --baz # The app window will not appear. # arg[1] and arg [2] without prefix open ./demoapp.app --args foo bar --baz # The app window will not appear. # single - in front of the first two arguments open ./demoapp.app --args -foo -bar baz # The app window will not appear. # single - in front of the first three arguments open ./demoapp.app --args -foo -bar -baz bob # App window displays as expected No idea what is going on but I suspect macOS does some pre-processing before launching the app, for example you can do stuff like open /Applications/SomeApp.app --args -AppleLanguages '(de)' to run using a specific language. I presume the OS is pre-processing arguments before launching the app proper. If I compile the app using Xcode 15.4 then this issue is not present. Also Apps compiled with Xcode 16 do not exhibit the issue on macOS 14 or earlier. It's a specific Xcode 16, macOS 15 thing in the way the app is compiled that makes it behave this way. I hope I've explained it correctly, but it's very easy to replicate. I filed a feedback for it (under a different apple account), FB15577018. Any insight into what's going on here would be helpful. Also if there's any compiler flags I could be setting. In my actual project, I'm not making any other changes. The same code compiled under Xcode 16 (.0 or .1RC) behaves differently to Xcode 15.4.

I installed Beta 4 of VisionOS 2 and now whenever I take the headset off nothing works after putting it back on except passthrough until the device is rebooted. This is somewhat inconvenient. I've raised it as a feedback but wondering if this is something others have noticed.

I have an app that I would like to register a launchd agent at the login window. my plist looks like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>RunAtLoad</key> <true/> <key>LimitLoadToSessionType</key> <array> <string>LoginWindow</string> </array> <key>AssociatedBundleIdentifiers</key> <string>com.myapp</string> <key>Label</key> <string>com.myapp.login-window</string> <key>ProgramArguments</key> <array> <string>/usr/local/myapp.app/Contents/MacOS/myapp-agent</string> <string>--login-window-agent</string> </array> </dict> </plist> If I manually copy the com.myapp.loginwindow.plist to /Library/LaunchAgents and load it manually it works as I'd expect If I use SMAppService though it does not work: let service = SMAppService.agent(plistName: "com.myapp.login-window.plist") do { try service.register() } catch let error { print(error.localizedDescription) } I get: The operation couldn’t be completed. Service cannot load in requested session. That makes sense as I'm not at the login window when I run that routine. However checking service.status() (with formatting) I get LaunchAgent(com.myapp.login-window.plist) status: Enabled which would suggest that it's loaded, yet when I log out or reboot and I'm at the login window the agent is not running. Indeed the agent does not appear in launchctl list I'm not sure what else to check to see what's going on. I've tested loading LaunchAgents and LaunchDaemons in other contexts using the ServiceManagement framework and these all work as I'd expect once approved. It's just the LoginWindow agent that is having issues.

I have a project that requires a fixed window size. In previous versions of Xcode when I compile the project with the following : struct MyApp: App {     var body: some Scene {         WindowGroup {             ContentView()                 .frame(width: 800, height: 600)         }     } } It will result in a window with a fixed size of 800x600 (i.e. the window inherits the fixed content size) With Xcode 14 and macOS Ventura, this is no longer the case. The above code compiles but now the window is resizable, with the content inhabiting an 800x600 area. In Ventura there is the   .windowResizability(.contentSize) property but this is macOS 13 only. I need my app to be able to support macOS 11 and 12 and now the window behaviour is broken with the latest Xcode. Is there any way to get around this that doesn't involve running a seperate macOS 12/Xcode 13 environment?

I'm trying to get a swiftui application to display at the macos login window. I can set canBecomeVisibleWithoutLogin but it appears that the code execution doesn't even get that far. When running, all the code in my App { init() method gets executed but anything in : var body: some Scene { WindowGroup { ... never runs. is this a limitation of the SwiftUI app lifecycle in this environment?

I'm making a command line utility and I'd like to check the Focus (nee do not disturb) status which requires the Communications Notifications entitlement as per https://developer.apple.com/forums/thread/682143 The utility itself is not sandboxed. as there is no app bundle, is there a way to assign or embed the entitlement into the binary so I can get access to things like INFocusStatusCenter.default.focusStatus.isFocused (if indeed that is relevant in macOS 12)